持續整合和持續發佈，除了解決工程師的痛點之外，也可以預防人工處理可能會產生的錯誤，舉例來說，上傳錯誤的版本交給驗證人員。延續這個原則，當目前的產品跟專案想要建立 CI/CD 機制時，先不管名詞先想想心中想要解決什麼問題。先求解決最大痛點，然後再慢慢地一步步到位。可是一步步地來不是很慢嗎？要做到什麼時候？

當要建立機制，就沒有做完的一天。功能會迭代、產品會有新功能、專案使用的環境會需要升級，機器也會有作業系統升級的問題等等。沒有做完的一天，那是不是就見招拆招一一進行了，畢竟計畫永遠趕不上變化。

不同的公司和團隊要建置 CI/CD 不一定是 Android 工程師來負責，可能有專門的職能角色，或是整個機制是分屬不同部門來處理。但在規劃的時候，先畫出你心中的想要的自動化有哪些，就像 30 天挑戰當中的那些故事們：

• 在將分支推回遠端的時候就可以直接發版
• 在提交 Pull Request 之前，可以 Testing 執行無誤才能提交異動
• 測試完畢之後，也可以直接上傳正式版到 Google Play Console 進行審核

以上可能是你心中想要解決的問題，或是許願的目標是什麼，在列出 TODO 清單之後。下一步驟想想每一個步驟需要什麼資訊跟技術。接下來就以分支推回遠端時可以直接發版，列出每一個步驟的期望有哪些：

1. 程式碼異動 （Commit）
2. 將分支推回遠端
3. 程式碼品質掃描
   a. 失敗：發送通知到群組頻道上
   b. 成功：開始執行測試們
4. 執行各種測試成功
   a. 失敗：發送通知到群組頻道上
   b. 成功：執行發版流程

列出每一個步驟的行為後，接下來在設計流程的最後一篇來看看如何實踐。